For the purposes of tracking transactions and determining billing, there are two conventional types of on-line services, each relying on an associated protocol or algorithm. In one type of service, a service provider such as an Internet service provider (ISP), charges a user a fee for the right to use the service for a limited period of time. The user may log onto the service as many times as she would like within a specified time period (e.g. one month), without being charged for each individual access. However, the ISP user is charged whether or not the service is used. In a variation of that system, a user may be charged for each access as a separate billing event.
There are also conventional tracking systems for tracking reserved access, such as, for example, a hotel room or a rental car. A customer may make a reservation with the service provider. If the customer makes but does not show up for a reservation, and has not guaranteed the reservation with pre-payment, the hotel or car rental company simply drops the reservation and the customer is not charged. Such systems typically allow the customer to reserve and to later access the room or car for specific dates, and also permits the customer to extend the time period of that access, without making another reservation. In a variation of that system, where the customer guarantees the reservation, the customer is charged for the reserved access, regardless of whether the room or car is actually used.
While such systems are adequate for tracking and billing certain types of services, there exists a need for an alternative system and method for tracking transactions and determining charges which permits a user to establish, via a single authorization, multiple access to a service during a period of time, where each event of access is not individually billed. There exists a need for a system and method which does not create a billable charge for a user authorization if the user does not actually access the service. Furthermore, there is a need for a system and method, which requires a user to initiate a new authorization after the original authorization has expired, in order to create a chain of authorization and access events. Additionally, there exists a need for a system and method that provides a plurality of devices local to the user, in order to create, store and transmit records of authorization and access to a remote central processor in a secure manner.
The following terms as used herein have the associated meanings as described below.
An authorization transaction is a record generated when a user authorizes a charge for an access right.
An access transaction is a record generated when the user exercises the right of access granted by the authorization transaction.
A matching transaction is an event that occurs when an access transaction matches an authorization transaction, which is only when they are from the same customer, for the same service, and the starting time for the access falls within the duration of the authorization. A user is charged when a matching transaction occurs.
A validated authorization is an authorization transaction with at least one matching access transaction.
A Billable Content Unit (BCU) provides access to the service, e.g., a BCU may be in the form of a digital video disc.
A Set Top Box (STB) is a device that has the capability to play a video content and to also keep a journal of billable and nonbillable activities and to transmit the journal to a central database host and transaction processor.
A journal is a log of the activities of a particular STB. It contains digital tickets (as defined below) and play records (as defined below).
A digital ticket ("ticket") is a journal entry recording a user authorization, i.e. a user agreeing to be billed for the access rights to a BCU for a stated time interval. Every digital ticket contains a unique serial number, a start time, a duration, the account number of the STB that created it, and the serial number of the accessed BCU. A digital ticket represents an authorization transaction.
A play is a journal entry recording that the user accessed a BCU during the duration of a digital ticket. A play contains a start time, a duration, the serial number of the digital ticket that allowed the play, the account number of the STB that created it, and the serial number of the accessed BCU. A play represents an access transaction.